Frontend Conference 2019
聞いた発表
AWSを活用したフロントエンド開発
当日は聞けなかった発表
その他
Web制作現場のディレクションを支えるGitHub
Angular
Vue
React
デザイン系
技術とは関係ない感想
こんなところに書いても主催者には伝わらないので愚痴っぽくなるが、あくまでも来年の自分のためのメモって感じで書いている
Wi-Fiが用意されていない
8000円払った人のみ？
なので、いろいろメモする環境を整えるために最初のほう聞けなかった
というか、このとき初めてLINEモバイルでもネット共有出来ることに気付いた
スクボはオフライン時はReadOnlyで、書きかけのもののみ書ける感じの仕様になっているので、1分で良いからネットに繋がせて〜ってなってた
VSCodeはオフラインのせいか、開発者ツールが落ちまくってメモすらできなかったのでまじで詰むかと思った
最悪スマホで全部メモするか？？？とか思ったがネット共有できたので耐えた
スクボ完全オフラインでも使えるようになってほしー
電源も用意されてない
8000円払った人のみ？
13:00~17:00まで電源供給の瞬間がないのでビビってたがなんとか耐えた
受付の効率が悪い
めっっちゃ人並んでた
受付対応する人が二人しかいなかった
受付時にその場でアンケートを書かせるのでめっちゃアレ
このカンファレンス専用のIonic Framewark製アプリが配布されていた
無駄にクオリティ高くて、こういうの良いなって思った
当日はめっちゃ重宝した
部屋のキャパと参加者数がマッチしていない
始まる前から並んでいるのに入れない人がたくさんいた
まだまだ部屋に入るスペースありそうなのにスタッフが全力で、「満席なのでこれ以上は無理です」って言ってたのが謎だった
前の発表を聞いた人は次の発表時も優先的にその会場に居座り続けられるので、並ぶぐらいならこの部屋のまま聞くかーって感じになった
午後の方で、A会場のを聞きたい→AかBか迷ってる→Aのを聞きたいってのがあったとき、並ぶアレだしA→A→Aにしよ、ってなった
申し込みフォームには通常(2000円), 懇親会あり(6000円), プレミアム(8000)があった
今回は通常でいった
応募フォームではプレミアムの説明が殆どなかったが、推測すると
ノベルティ、Wi-Fi、電源、会場内優先席という感じかな、って感じだった
会場内優先席はめっちゃ並んでいても無関係に最前席に座れるという感じ
僕は運良く全ての時間の発表を聞けたが、一緒に来てた人は何個か入りそびれていた
まぁ、AWSサミットのときとかとは違って申し込み時はどの発表を聞くかアンケートみたいなものもなかったのでそんな感じになるのだろう
発表自体は当たり外れがあったなーという感じ
スライドのview数やはてブ数も顕著に差が出ている
来年もまた参加したいって思ったけど、帰り道にボク個人について「勉強会に参加する意味とは？」をもうちょっと考えたほうが良いな、ッテ気分になった
聞きメモ
Cache API
windowやworkerで使える
有効期限の設定ができない
dev tool>application>cacheのとこ
key-valueなのかなmrsekut.icon
cache API
cache API自体には有効期限がないが、localStrateを使うなどして有効期限を指定できる
storageEstimate
キャッシュの使用量や上限がわかる
いろいろプログラマブルにキャッシュをいじることができる
しらべたい
tipsysというアプリ
女性が女性とマッチングするためのアプリ
Ionicで作った
ionicでPWA作るん？
フロントエンドは進化の速度が早いので、気を抜くとすぐにレガシーになる
言語のバージョンもそうだし、フレームワークやライブラリのバージョンもそう
PWAみたいな新しいあれもあるし
js→tsの以降、ビルド周りがつらそう
レガシーと言うか、設計がそもそもやばくねmrsekut.icon
どちらかといえば技術選定ミスっぽい
class-style APIとは
vueの話かmrsekut.icon
ビジネスロジックをViewフレームワークとは別の場所に書くのは、フレームワークが変わっても耐えるようにするため
Vue→Reactになっても最小限の修正で済む
スナップショットテスト
FWで生成したHTMLを比較してテストする
リプレイス前のテストコードがリプレイス後に動かない、などがあった
テストコード自体はあるけど、実際に問題が起こるまでは、そのテストはskipさせる
ゆーざーがネイティブに慣れすぎてるのでwebにもその速度が求められる
物理的な時間と、知覚する時間
数値で見れる時間だけが問題なわけではない
UX, UX的な工夫によってカバーできる
昔のamazonのサイトはロードする時間は遅かったが、ユーザーの評価は高かった
How
ライブラリを更新しよう
バージョンが上がればパフォーマンスがよくなることが多い
不要なコードの削除
unusedなものってこと？mrsekut.icon
なんで遅くなる？
dev toolのcoverageを使うと、ロードしたjsの中で何%が使われているかが見れる
50%が使われていない、はまだ良い方
例えばlodashは一つの関数を使うために全部ロードしてるが、一つだけ選んでロードすることもできる
from lodash/hogeみたいに書く
コードスプリッティング
初期ロードに不要なものは必要になったタイミングでロードする
lazyみたいな
必要になっったとき、その画像が司会に入ったタイミングでロードされる
コードスプリッティングがパフォーマンス的に有効だったとよくテックブログに書かれているらしい
twitterとか
ライブラリがモジュール化されていると、ライブラリごとにキャッシュすることができる
コンポーネントでもどうようにコンポーネントごとにキャッシュできる
し、lazy的にロードすることができる
結果的に、ユーザーが数日間でロードする量が減る
SIの対策
Ciritical Rendering Path
Above the Fold, Below the Fold
<script async../>とか<script defer .../>とか
AWSを活用したフロントエンド開発
フロントエンドエンジニアファースト
AWS AppSync
リアルタイムのデータアクセスと恒真
GraphQLを使う
オフラインのデータ同期
AmplifyでAppSyncの設定ができる
私達は流行っているからなどの理由であまり考えずにSPAを採用しているが、本当にそれはSPAでないといけないのか？を問うた発表
LINEのUITコミュニティ
podcastもやってる
Tree.md
STIMLUS
Gridsome
VueのGatsby
UX要件、DX要件の軸で考える
オーバーエンジニアリングも危険だよ
要件に対する、オーバーエンジニアリング、アンダーエンジニなリングを意識し、言語化できないといけない
reactはjavascript:hogehogeなどのスキームは自動的に削除したりはしない
DOMPurify
エスケープ処理をするライブラリ
memo
tsって配列がからではないことを型で表現できるのかな
このpropsには絶対lengthが1以上じゃないとだめだよ、的な
サニタイザーとは